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This month Wilf Hey 
looks at the new VAT rate, 
rounding problems, and 
what to do if your CAPS 
LOCK key wont work. 
And a new challenge — 
can you write a program 
that writes itself? 


suppose you’ ve hardly noticed that 

things seem to be getting a bit 

more expensive these days. In 
their unrelenting fight to keep prices 
down (?), the ‘powers that be’ have 
increased the VAT rate to 17.5 percent — 
just after we published that rather nifty 
little pop-up VAT calculator, set to 15 
percent (issue 54 SuperDisk). 

However, there’s no need to delete 
this program from your system as there 
is an extremely easy way to make the 
VAT calculator work at the new rate of 
17.5 percent. Simply run the program 
from the MS-DOS command line in the 
following way: 


VAT 17.5 [Enter] 


That’s all there is to it. Until you (or the 
Chancellor) want to make another 
alteration, the calculator will work at the 
new VAT rate — from the very next time 
it pops up. 

Businessmen (and women) among 
you will remember that you used to be 
able to calculate the VAT on your net 
receipts, by multiplying by three, then 
dividing by 23. Naturally, this no longer 
works — but the new ‘trick’ is not too 
much worse. I present it here as a public 
service: multiply your net receipts by 
seven, and then divide by 47, to find out 


how much of your net total actually 
belongs to HMC & E. 


MISCALCULATIONS 

One little problem I set a few months 
ago brought in a few surprise letters. The 
problem concerned the ‘2’ bit not 
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appearing in the binary expression of a 
square — four readers wrote in telling me 
that they had found squares that did have 
this bit. Let’s have a look at where they 
went wrong? 

The BASIC programming language — 
in all the forms I have ever encountered 
— performs its calculations in rather a 
peculiar way. Unless you tell it 
specifically (using DEFINT, or adding 
the [%] suffix to all names in the 
calculation), the whole thing is done in 
“single-precision’ instead of ‘integer’. I 
suppose this is a reasonable method as it 
will deal with any fractions that crop up. 
However, all that converting back and 
forth between single-precision (for the 
calculation) and integer (for the final 
result) means something is bound to go 
slightly wrong somewhere — just because 
of rounding, for example. 

One child in our family (my younger 
sister’s older brother) attempted to make 
use of this sort of conversion error. For 
his sixth birthday (pre-decimal) he 
received a half-crown. Accompanying 
his mother that day on a shopping 
expedition, he exchanged his birthday 
coin for threepences at one shop, then 
for twopences at the next. At a third 
shop the twopences were exchanged for 
sixpences, and his mother asked the boy 
why he was doing all this coin-changing. 
The child replied, ‘Some time, 
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somebody’s going to make a 
mistake...and it won’t be me!’ 


ROUND AND ABOUT 

I once worked for a large life assurance 
company, whose financial men imposed 
funny-sounding rules about rounding 
quantities; for example, they would 
round down on 49p and up on 51p — but 
on 50p, they would round down half the 
time, up the other half. To this day, I 
cannot see how this is logical or fair — 
unless they knew that you couldn’t have 
an exact number of pounds. 

Even without strange rules like that, 
rounding numbers can be a bit of a 
vexing problem. Many a programmer — 
in BASIC, Pascal, C, Fortran and 
COBOL, and probably most other 
languages — has relied on internal 
procedures, largely unknown to them, to 
cope with rounding during calculations. 
Unfortunately once you leave the realm 
of ordinary integers things get a bit 
cloudy, and one compiler will produce 
slightly different results to another. 
Every so often, I have found calculation 
differences that were more than ‘slight’. 
Do you really trust your compiler to put 
the best code for rounding? 

Let me give you a simple expression 
that will reliably round the non-integer 
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variable AMT (short for AMOUNT) in 
the normal manner; that is, if the 
fractional part is 0.5 or more, the 
rounding is upwards. 


AMT = INT( AMT + AMT - INT(AMT) ) 


You may have to modify the syntax for- 
your favourite language, but most 
languages have the INT() function 
available — even GW-BASIC. 

I’ve had to ‘force’ amounts upward 
on occasion — for example, 17.01 is to be 
rounded to 18. If you need to do this, 
try this: 


AMT = INT( AMT + 0.99 ) 


Of course, we could have used the same 
method for ordinary rounding, 
substituting 0.5 for 0.99, but the earlier 
one produces (in Clarion, and in my C 
compiler) slightly better code — and it 
looks nicer to me. 


SOURCE CODE GENERATOR 
This month I present a new challenge — 
one that arises from a game we 
programmers used to play some years 
ago. There are prizes for the first six 
entries; your program (on diskette, 
please) should generate its own source 


code as output. Here are the rules: 

1. No input is allowed from outside 
the program itself 

2. Output can be on diskette or disk 

3. Output should be valid, error-free 
source code 

4. When the output is compiled (and 
linked) by ordinary means, the result is 
identical to the program itself — whether 
BAS, EXE or COM. 

5. Results must run on a standard PC, 
and terminate properly 

6. Any recognised computer program 
may be used; if it’s a rare bird, please 
provide me the means to test your entry! 


RAISING THE DEAD 
Have any of you heard of the ‘Zombie 
Wall’ — how to program this technique, 
and why? In the near future we’ ll see 
how to employ Zombies and Walls in 
several programming languages. If you 
know the technique, please write in with 
your comments. 

Tips, arguments and ideas are 
gratefully received by: 
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